When establishing application IP connectivity directly between two devices on an IP network, it is usually achievable by directing IP packets from the source IP address of the sender to the IP address of the receiver and vice versa. However, with the growth of corporate and private local area networks (LANs), IP connectivity may be funneled via a common connection sharing device commonly know as a Network Address Translator (NAT). This device masks the originating address of one or many devices on one network so that they appear as one common address on another network. By way of example, connection from the public Internet to a device located on the private LAN is not possible until the device located on the private LAN has first opened a pathway (“pinhole”) to it with the NAT device for which IP connectivity can be established. When using client-server applications such as web servers where the client behind NAT (CBN) is requesting service from a web site, the connection originates from the CBN and a pinhole is opened in the NAT device to facilitate IP connectivity.
Where peer type (exchange between equals neither a server or a client) communication devices require interconnectivity, these devices must first open pinholes from inside of the respective NAT devices to facilitate receiving communication. Not all NAT devices behave in a similar predictable manner; some can be easier to traverse, while others require a higher degree of complexity to establish direct IP connectivity. When the latter is the case, and both communication devices are clients behind NATs (“CBN”), the difficulty is multiplied.
Existing methodologies have included the provisioning of IP connectivity either manually or using some form of IP communication, to the NAT device to allow other communication devices to connect to the CBN (this is commonly known as port forwarding), provide tunneling facilities which will build a direct IP tunnel between the devices for connectivity to flow through (as an example, an IPSec tunnel) or having the communication devices contact an intermediate facilitating entity (node) that will assist by routing the IP connectivity through itself to enable connectivity between the devices. Intermediate facilitating entities may take the form of a specifically designed device, which will route the IP connectivity through (commonly known as a “media proxy” or simply “proxy”), or another like communication device, which acts as a go-between between two or more other communication devices (commonly known as peer to peer).
Other work in facilitating direct IP connectivity has primarily focused on the communication devices “learning” about the NAT devices they reside behind, and listing possible IP address and port candidates (or guesses) to facilitate direct IP connectivity. Candidates may be compiled from information provided in the signaling messages, as well as observed IP address and ports from which packets are transmitted. Each device then goes through a routine of hit and miss, trial and error until a successful pathway, if possible, is found. This routine may include trying different IP protocols, different IP addresses (for example, internal address, public IP address of the remote NAT device) or trying different port numbers.
In view of the above, it would be desirable if the communication devices were able to simply, successfully and efficiently establish IP connectivity directly between each other without routing pathways through intermediate facilitating entities, which may add additional cost to provisioning or operating of a service, and without requiring a hit and miss guessing type methodology which may result in failed connectivity.